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BASIC COMMAND REPRESENTATION OF QUALITY OF SERVICE POLICIES 

FIELD OF THE INVENTION 

The present invention generally relates to data processing in a network 
5 communication system. The invention relates more specifically to methods and apparatus 
that provide a basic command representation of abstract policies that define quality of 
service treatments for network data flows. 
BACKGROUND OF THE INVENTION 

A computer network generally comprises a plurality of interconnected electronic 

10 elements that transmit or receive data frames. A common type of computer network is a 
local area network ("LAN") that generally comprises a privately owned network within a 
single building or campus. LANs employ a data communication protocol such as 
Ethernet, FDDI, or Token Ring, which defines the functions performed by the data link 
and physical layers of the LAN. The Open Systems Interconnection (OSI) Reference 

15 Model is used to identify the nature of communications that occur at different logical 
levels of a network, hi many instances, multiple LANs may be interconnected by point- 
to-point links, microwave transceivers, satellite hookups, etc., to form a wide area 
network ("WAN"), campus network or Intranet, These internetworks may be coupled 
through one or more gateways to the global, packet-switched internetwork knows as 

20 fiitemet. 

Each network element operates using network communication software, e.g., in 
accordance with Transport Control Protocol/hitemet Protocol (TCP/IP). TCP/IP 
generally consists of rules defining how network elements interact, and defines 
communication layers that include a transport layer and a network layer. At the transport 
25 layer, TCP/IP includes both the User Data Protocol (UDP), which is a connectionless 
transport protocol, and TCP, which is a rehable, connection-otiented transport protocol. 
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One or more intermediate network devices are often used to couple LANs 
together and allow the corresponding entities to exchange information. A bridge may be 
used to provide a "bridging" function between two or more LANs, or a switch may be 
utilized to provide a "switching" function for transferring information, such as data 
5 frames or packets, among entities of a computer network. Switches may operate at 

various levels of the communication stack. For example, a switch may operate at Layer 2 
(the data link layer, in the OSI Reference Model), which includes the Logical Link 
Control (LLC) and Media Access Control (MAC) sub-layers. 

Other intermediate devices, e.g., routers, may operate at higher layers, such as 

10 Layer 3, which in TCP/IP networks corresponds to the Internet Protocol (ff) layer. IP 
data packets each include a header that contains an IP source address and an IP 
destination address. Routers or Layer 3 switches may re-assemble or convert received 
data frames from one LAN standard (e.g., Ethemet) to another (e.g., Token Ring). Thus, 
Layer 3 devices are often used to interconnect dissimilar subnetworks. Some Layer 3 

15 intermediate network devices may also examine the transport layer headers of received 
messages to identify the corresponding TCP or UDP port numbers being utilized by the 
corresponding network entities. Many applications are assigned specific, fixed TCP 
and/or UDP port numbers in accordance with Request For Comments (RFC) 1700. For 
example, TCP/UDP port 80 corresponds to the Hypertext Transport Protocol (HTTP), 

20 while port 21 corresponds to File Transfer Protocol (FTP) service. 

Computer networks include numerous services and resources for use in moving 
traffic throughout the network. For example, different network links, such as Fast 
Ethemet, Asynchronous Transfer Mode (ATM) channels, network tunnels, satellite links, 
etc., offer unique speed and bandwidth capabilities. Particular intermediate devices also 

25 include specific resources or services, such as number of priority queues, filter settings, 
availability of different queue selection strategies, congestion control algorithms, etc. 
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Individual frames or packets can be marked so that intermediate devices may treat 
them in a predetermined manner. For example, the Institute of Electrical and Electronics 
Engineers (IEEE) describes additional information for the MAC header of Data Link 
Layer frames in Appendix 802. Ip to the 802. ID bridge standard. 
5 A Data Link frame includes a MAC destination address (DA) field, a MAC 

source address (SA) field and a data field. According to the 802. IQ standard, a 
user_priority field, among others, is inserted after the MAC S A field. The user_priority 
field 108 may be loaded with a predetermined value (e.g., 0-7) that is associated with a 
particular quality of service treatment for the packet, such as background, best effort, 
10 excellent effort, etc. Network devices, upon examining the user_priority field of received 
Data Link frames, apply the corresponding treatment to the frames. For example, an 
intermediate device may have a plurality of transmission priority queues per port, and 
may assign frames to different queues of a destination port on the basis of the frame's 
user priority value. 

15 A Network Layer packet based on Internet Protocol includes a type_of_service 

(ToS) field, a protocol field, an IP source address (SA) field, an IP destination address 
(DA) field and a data field. The ToS field is used to specify a particular service to be 
appUed to the packet, such as high reliabiUty, fast dehvery, accurate delivery, etc., and 
comprises a number of sub-fields. The sub-fields may include a 3-bit JP precedence (IPP) 

20 field and three one-bit flags that signify Delay, Throughput, and Reliability. By setting 
the flags, a device may indicate whether delay, throughput, or reliability is most 
important for the traffic associated with the packet. Version 6 of Intemet Protocol (IPv6) 
defines a traffic class field, which is also intended to be used for defining the type of 
service to be applied to the associated packet. 

25 A working group of the Intemet Engineering Task Force (IETF) has proposed 

replacing the ToS field of Network Layer packets with a one-octet differentiated services 
(DS) field that can be loaded with a differentiated services codepoint value. Layer 3 
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devices that are DS compliant apply a particular per-hop forwarding behavior to data 
packets based on the contents of the DS field. Examples of per-hop forwarding behaviors 
include expedited forwarding and assured forwarding. The DS field is typically loaded by 
DS compliant intermediate devices located at the border of a DS domain, which is a set 
5 of DS compliant intermediate devices under common network administration. Thereafter, 
interior DS compliant devices along the path apply the corresponding forwarding 
behavior to the packet, 

A Transport Layer packet includes a source port field, a destination port field, and 
a data field, among others. Such fields preferably are loaded with the TCP or UDP port 

10 numbers that are utilized by corresponding network entities. 

To interconnect dispersed computer networks, many organizations rely on the 
infrastructure and facilities of Internet Service Providers (ISPs). Each organization enters 
into a service-level agreement with its ISP. The service level agreements include one or 
more traffic specifications. The traffic specifications may place limits on the amount of 

15 resources that the organization may consume for a given price. For example, an 

organization may agree not to send traffic that exceeds a certain bandwidth, e.g., 1 Mb/s. 
Traffic entering the service provider's network is monitored to ensure that it comphes 
with the relevant traffic specifications and is thus "in profile." Traffic that exceeds a 
traffic specification, and is therefore "out of profile," may be dropped or shaped or may 

20 cause an accounting change. Altematively, the service provider may mark the traffic as 
exceeding the traffic specification, but allow it to proceed through the network anyway. If 
there is congestion, an intermediate network device may drop such marked traffic first in 
an effort to relieve the congestion, 

A process executing at a network entity may generate hundreds or thousands of 

25 traffic flows that are transmitted across a network. Generally, a traffic flow is a set of 
messages (frames and/or packets) that typically correspond to a particular task, 
transaction or operation (e.g., a print transaction) and may be identified by various 
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network and transport parameters, such as source and destination IP addresses, source 
and destination TCPAJDP port numbers, and transport protocol. 

The treatment that is applied to different traffic flows may vary depending on the 
particular traffic flow at issue. For example, an online trading application may generate 
5 stock quote messages, stock transaction messages, transaction status messages, corporate 
financial information messages, print messages, data backup messages, etc. A network 
administrator may wish to apply a different policy or service treatment ("quality of 
service" or "QoS") to each traffic flow. For example, the network administrator may 
want a stock quote message to be given higher priority than a print transaction, or may 

10 wish to assign a higher priority to packets relating to a $1 million stock transaction 

message for a premium client as compared to than a $100 stock transaction message for a 
standard customer. 

In current approaches, QoS poHcies may be defined in abstract form, but 
deployment of the policies requires conversion of the policies from the abstract format 

15 into one or more commands formatted according to the Command line Interface (CLI) or 
similar command language. Some such command languages have arcane syntactical 
requirements and numerous parameter values. Thus, creating correct CLI conmiands may 
require extensive knowledge of routers and the CLI language, commands and parameters. 
Based on the foregoing, there is a clear need in this field for a way to create 

20 quality of service policies in an intermediate representation that is more abstract than CLI 
commands, but more specific than a policy itself. 

Another problem in this field involves deploying new pohcies to devices that 
already contain other configuration information. Each QoS policy is deployed to or 
deleted from a device on top of a current device configuration. It is critical to deploy the 

25 QoS policy without disrupting the pre-existing configuration, and without introducing 
operational changes that counteract existing operational modes. 
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Accordingly, there is a specific need for a way to represent QoS policies in 
abstract manner, while taking into account the current configuration of a device. 
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SUMMARY OF THE INVENTION 

The foregoing needs, and other needs and objects that will become apparent from 
the following description, are fulfilled by the present invention, which comprises, in one 
embodiment, a method of converting an abstract quality of service policy into a new 
5 configuration for one or more network devices of a managed network, such as routers. 
The pohcy expresses a quality of service treatment of traffic flows that are carried by the 
network, at a high level of abstraction, and is created and stored using a quality of service 
pohcy management system. 

According to an embodiment of the method, the abstract quality of service policy 

10 is received and converted into a first set of one or more basic commands. A current 
configuration of one of the network devices is obtained, e.g., through device discovery. 
The configuration is received in the form of one or more first command line interface 
(CLI) commands that represent the current configuration of the network device. A second 
set of one or more basic commands that correspond to the current configuration of the 

15 network device is determined, based on the first CLI conmiands. The first and second sets 
of basic commands are transformed into one or more second CLI commands which, when 
executed by the network device, will create a new configuration for the network device 
that implements the abstract quality of service poUcy. Merging and aggregation, based on 
state values associated with the basic commands, is carried out to remove any duplicate 

20 commands. 

As a result, CLI commands providing a new configuration that implements the 
policy are deployed to the device. The basic commands are expressed at a level of 
abstraction lower than the abstract policy and higher than the CLI commands. 

In one embodiment, a software model defines basic command objects that can 
25 represent CLI commands, and can be used as the building blocks of an abstract conmiand 
structure. The objects contain poUcy data itself, and can also express relations between a 
group of such objects. An abstract policy can be represented with all appropriate 
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elements, e.g., filter, action parameters, device interface identifiers, and related data of 
resources on the device for each conmiand. In a deployment process, basic command 
objects are created based on parsing an existing device configuration; such objects serve 
as a starting point for creating a new QoS configuration. The abstract policies, which are 
5 previously defined and stored in a database, are also translated into other basic command 
objects. The two sets of basic conmiand objects are merged, resulting in a new QoS 
configuration for the device, expressed in CLI commands. 

Other features and aspects will become apparent from the following description 
and claims. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

The present invention is illustrated by way of example, and not by way of 
limitation, in the figures of the accompanying drawings and in which like reference 
numerals refer to similar elements and in which: 
5 FIG. 1 is a simplified block diagram of communicating a quality of service policy 

to a network device. 

FIG. 2A is a block diagram of a quality of service management system that 
includes basic command processing logic, 

FIG. 2B is a block diagram of an abstract policy and its elements. 
10 HG. 2C is a block diagram of a basic command and its elements. 

FIG. 3A is a flow diagram of a process of transforming an abstract quality of 
service policy into a device configuration. 

FIG. 3B is a flow diagram of a process of abstract policy translation. 

HG. 3C is a flow diagram of a process of device configuration upload. 
15 HG. 3D is a flow diagram of a process of merging and aggregation. 

FIG. 3E is a flow diagram of a process of device configuration representation. 

FIG. 4 is a block diagram of a computer system with which an embodiment may 
be used. 
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DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 

A method and apparatus providing basic command representation of quality of 
service policies for treatment of network data flows is described. In the following 
description, for the purposes of explanation, numerous specific details are set forth in 
5 order to provide a thorough understanding of the present invention. It will be apparent, 
however, to one skilled in the art that the present invention may be practiced without 
these specific details. In other instances, well-known structures and devices are shown in 
block diagram form in order to avoid unnecessarily obscuring the present invention. 

TRANSFORMING ABSTRACT QUALITY OF SERVICE POLICIES INTO 
10 DEVICE CONFIGURATION INFORMATION 

This disclosure generally relates to transforming abstract quahty of service 
policies into device configuration information. In general, users of network device quality 
of service policy management systems desire to define quality of service policies in a 
high-level, abstract manner, and deploy the poUcies to network devices without any 
1 5 intermediate manual action. 

FIG. 1 is a simplified block diagram that illustrates a user view of communicating 
a quality of service pohcy to a network device. A quality of service pohcy 2 is deployed 
to a network device 4. The quality of service policy 2 may be defined by a user of a 
quality of service policy management system. The network device 4 may be a switch, 
20 router, or other device in a network. 

Quality of service policies specify, in an abstract manner, what quahty of service 
treatment should be applied to a particular type of network traffic. An example of a 
poUcy definition is: 

"ERPTraffic," "Protocol is TCP and Source is ERPServer,'' "Coloring, 
25 Precedence=Critical(5)" 

which means, "for traffic associated with an Enterprise Resource Planning (ERP) 
application, when the protocol is TCP and the traffic originates from the ERPServer, 
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apply packet coloring with a precedence value of Critical." Policies may call for packet 
coloring, traffic shaping, limiting actions on routers or switches, priority queuing, custom 
queuing, etc. To deploy a quality of service policy to one or more devices in a network, 
the policy management system converts each poUcy into one or more Command Line 

5 Interface (CU) commands that the operating system of the device can process. In some 
cases, new access control lists are created in the device. The CU commands and access 
control lists that implement a policy are referred to as a new device configuration. When 
a device executes the CLI commands of a new configuration, the device becomes re- 
configured and will implement the quality of service policy as the device handles 

10 network traffic. 

- - STUUCTURAL OVERVIEW 

FIG. 2A is a block diagram of a quality of service management system that 
includes basic command processing logic. 

A quality of service management system 102 includes, among other elements, one 
15 or more stored quality of service policies 104, basic commands 106, and CLI conmiands 
108. Basic command processing logic 105 can create, manipulate and manage the 
poUcies 104, basic commands 106, and CLI commands 108. One or more CLI commands 
108, based on the pohcies 104, are deployed to one or more network devices 112 of a 
managed network 110. 

20 Basic command processing logic 105 may be implemented in the form of one or 

more subroutines, methods, or other software elements that form part of a larger quahty 
of service policy management system. An example of a quality of service policy 
management system in which such poUcies may be defined is Cisco QoS Policy Manager 
1.1, commercially available from Cisco Systems, Inc. Network device 112 of FIG. 2A is 

25 one or more switches, routers, gateways, etc. Network 1 10 is one or more local area 
networks, wide area networks, campus networks, internetworks, etc. 
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In one embodiment, software elements create and manage software objects that 
model abstractions involved in policy definition and deployment. The software model 
provides an easier and extendable mechanism for configuring of abstract high-level 
policies on a network device. Also, this model supports presentation of low-level device 
5 configuration as a set of abstract policies. In the preferred software model, the following 
elements are defined: Abstract policy, CLI conmiand, Basic Command. Each element is 
implemented as one or more programmatic objects, including methods, static variables, 
etc., in an object-oriented progranmiing language such as Java® or C+H-. 

FIG. 2B is a block diagram of an abstract policy and its constituent elements, as 
10 created and managed by a preferred embodiment. For purposes of illustrating an example, 
FIG. 2B is described with respect to the system of FIG. 2A. 

One or more Abstract Policy objects 202 are used for representing high-level 
policies that can be manipulated by the user. Thus, Abstract Policy objects 202 represent 
or model the information contained in each quality of service policy 104. The user can 
15 define an abstract policy on a device or device interface. Preferably, an Abstract Policy 
object 202 has the following methods: a Name method 204, a Parameters method 206, 
and a Basic command method 208. 

% 

The Name method 204 returns the literal ici^Btifier of the associated abstract 
policy as presented to users. The Parameters methoid 206 retums a set of parameters that 

20 are allowed for the abstract policy. The Basic command method 208 receives a device 
type value as a parameter, and retums a list of one or more basic commands 106 that are 
required for implementing the abstract pohcy on a network device. The type and number 
of basic commands can depend on the type of the device or device interface for which the 
abstract command is defined. 

25 Command-line interface (CLI) commands 108 are the low-level configuration 

commands that are understood by the operating system of a network device. For example, 
Cisco devices operate under control of Intemetworking Operating System (lOS), which 
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can process a particular set of CLI commands. The preferred embodiment operates in 
connection with existing CLI commands. Information about CLI conmiands may be 
obtained in order to analyze device configuration, or to deploy configuration information 
to a device. 

5 FIG. 2C is a block diagram of a basic command object and its constituent 

elements. Basic commands conceptually occupy a middle layer between abstract policies 
and CLI commands. Each basic conmiand contains information about which CLI 
commands are required to implement a given abstract policy on a network device of a 
certain type. A basic command can be created either from an abstract policy or from a set 

10 of CLI commands uploaded from a network device. 

In a preferred embodiment, each Basic Command object 210 has the following 
methods: ConmiandType, Mterfaceld, getCLI, getUndoCLI, State. The CommandType 
method 212 retums a value indicating the type of the Basic Conmiand. The Interfaceld 
method 214 retums a value of an identifier of the network device interface to which the 

15 basic command is to be applied. If no such value is set in the device, then the basic 
command is attached to the network device generally rather then to a specific interface. 

The GetCLI method 216 retums a list of CLI commands that implement the 
associated basic command, and which may be directly configured on a network device. 
The format of each CLI conmiand in the list is defined by the device operating system. A 

20 complementary method, the GetUndoCLI method 218, retums a list of CLI commands 
for removing elements of the device configuration that corresponds to the basic 
command. 

The State method 220 retums a state value reflecting the state of the basic 
command. Values retumed by the State method may be used in algorithms that analyze 
25 the configuration of the device. The State method 220 may retum one of the following 
values having the following meanings: 



50325-0124 (2145/64741) 



-13- 



DO - the basic command MUST be deployed to a device. The CLI 

commands returned by GetCLI should be used for configuration of 
the device. 

EXIST - the basic command is currently configured on a device. The 
5 basic command can be removed from the device or used in the nev^ 

configuration. 

NOT„FOR_USE the basic command is currently configured on a device 

and cannot be removed or used in a new configuration. 
UNDO - the basic command SHOULD be removed from the new 
10 configuration. The CLI commands returned by GetUndoCLI 

should be used. 
- FUNCTIONAL OVERVIEW 

FIG. 3A is a flow diagram of a process of transforming an abstract quality of 
service policy into a device configuration. In one embodiment, a process of representing 

15 abstract quality of service policies as one or more basic commands comprises an Abstract 
Pohcy Translation phase 302, a Device Configuration Upload phase 304, a Merging and 
Aggregation phase 306, and a Device Configuration Representation phase 308. Through 
successive execution of each phase shown in FIG. 3 A, an abstract quality of service 
policy is transformed into a new device configuration for one or more devices. 

20 FIG, 3B is a flow diagram of sub-steps that may be involved in the Abstract 

Policy Translation phase 302. As shown by block 310, each abstract quality of service 
policy that has been defined by a user using a quality of service policy management 
system is received and analyzed. la block 312, instances of basic commands are created 
to correspond with the abstract quality of service policy. The specific basic commands 

25 that are created for each abstract policy depend on the basic nature of the abstract policy, 
and the type of the network device and interface the policy is configured on. 
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As a result, an initial set of basic commands, implementing all abstract policies 
defined by the user, is created and stored, as shown by block 314. Block 314 also 
preferably involves assigning a state value of each basic command object in the set, when 
each basic command object is created, Basic commands in the final list that are created 
5 from the abstract pohcies that were received in the Abstract Policy Translation phase 302 
are assigned the state value "DO." 

FIG. 3C is a flow diagram of sub-steps that may be involved in Device 
Configuration Upload phase 304. 

In block 316, the current configuration of each device is received and analyzed. 
1 0 Current device configuration information may be obtained using a special CLI command 
(e.g., "show running config" on a Cisco router), or by other conventional means, such as 
device discovery processes that use one or more SNMP query messages to obtain MIB 
variable values, fii block 318, based on the current device configuration information 
received fi:om the device, the process determines one or more specific CLI commands 
1 5 that would create such configuration if sent to and executed by the operating system of 
the device. As a result, a list of CLI commands for the current device configuration is 
created and stored. 

As indicated by block 320, each CLI command in the hst is converted into one or 
more Basic Commands 210. The type of the created Basic Command is determined by 
20 the basic nature of the original CLI commands, and the type of the network device and 
interface these commands are effective for. As a result, a set of uploaded basic commands 
is created and stored, as indicated by block 322. 

Similar to block 314, block 322 also preferably involves assigning a state value to 
each basic command that is created. Basic commands in the final list that originate from 
25 the current device configuration are assigned the state value "UNDO" if the configuration 
is a candidate for removal, and otherwise receive the state value "NOT_FOR„USE." 
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FIG. 3D is a block diagram of the Merging and Aggregation phase 306. In this 
phase, generally, the process determines a minimal set of basic commands that are 
required for building a new device configuration from the existing one. Duplicate basic 
commands are eliminated and similar basic commands are merged into fewer basic 
5 conmiands. As a result, a final hst of basic commands is created and stored, and the final 
list of basic conmiands represents a new configuration for the device. The new 
configuration represents the abstract policies defined by the user. 

Specifically, as shown by block 324, in the Merging and Aggregation phase 306, 
tiie two sets of basic commands tiiat were created in tiie previous phases are compared to 
10 determine a minimal set of basic commands that will result in a new device configuration 
that both retains features of the current device configuration, and implements the abstract 
poUcy that was received in the Abstract Policy Translation phase 302. The initial Ust of 
basic commands and the list of uploaded basic commands are evaluated and merged, 
resulting in creating and storing a final Ust of basic commands, as shown by block 326. 
15 During the process of merging and evaluation in block 324, the basic commands from the 
two sets are compared and their states are changed according to the following rule. 

For two basic commands that have equal values of all parameters witiiout 
considering the value of the State parameter: If one has a state value of DO and 
tiie other has a state value of UNDO, then the commands are merged into one 
20 command that has a state value of EXIST, 

The output of this step is the final hst of basic commands of block 326, which can be 
used for creating a new configuration. 

FIG. 3E is a block diagram of sub-steps that may be involved in the Device 
Configuration Representation phase 308. As input, the final list of basic commands 322 
25 that was created in the previous phase is received. Each basic command in the final Ust of 
basic commands 322 is translated into one or more corresponding CLI commands based 
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on state values, as shown by block 324. In the preferred embodiment, in block 324 the 
following rules are observed: 

1 . If a basic command has a state value of "DO", then the getCLI 
method of that basic command is used to obtain the correct 

5 corresponding CLI command for that basic command. 

2. If the state value of a basic command is "UNDO", then the 
getUndoCLI method is used to obtain the corresponding CLI 
command. 

3. If the state value of a basic command is "EXIST" or 

1 0 "NOT__FOR_USE" then no corresponding CLI command is 

generated. 

The resulting set of CLI commands is deployed to the device, as shown by block 
326. When deployed to the device, the combined set of CLI commands changes the 
existing configuration to match the abstract policies. The CLI commands may be 

15 deployed to one or more devices using known techniques of device communication. 

As an example, assume that an abstract policy is defined for coloring packets that 
carry Web traffic. In the Abstract Policy Translation phase, the process creates the 
following basic commands: (1) a coloring basic command having a state value of "DO"; 
(2) an access control list basic command having a state value of "DO". 

20 In the Device Configuration Upload phase, the process analyzes the configuration 

of the device to which the pohcy will be applied. The process determines that the proper 
CLI commands are those relating to limiting web traffic. In response, the process creates 
the following basic commands: (1) a limiting basic command with a state value of 
"UNDO", (2) an access list basic command with a state value of "UNDO". 

25 In the Merging and Aggregation phase, the process creates a Limiting basic 

command with a state value of "UNDO"; a coloring basic command with a state value of 
"DO"; and an access Ust basic command with a state value of "EXIST". 
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- HARDWARE OVERVIEW 

FIG. 4 is a block diagram that illustrates a computer system 400 upon which an 
embodiment of the invention may be implemented. The preferred embodiment is 
implemented using one or more computer programs running on a network element such 

5 as a router device. Thus, in this embodiment, the computer system 400 is a router. 

Computer system 400 includes a bus 402 or other communication mechanism for 
communicating information, and a processor 404 coupled with bus 402 for processing 
information. Computer system 400 also includes a main memory 406, such as a random 
access memory (RAM), flash memory, or other dynamic storage device, coupled to bus 

10 402 for storing information and instructions to be executed by processor 404. Main 
memory 406 also may be used for storing temporary variables or other intermediate 
information during execution of instructions to be executed by processor 404. Computer 
system 400 further includes a read only memory (ROM) 408 or other static storage 
device coupled to bus 402 for storing static information and instructions for processor 

15 404. A storage device 410, such as a magnetic disk, flash memory or optical disk, is 
provided and coupled to bus 402 for storing information and instructions. 

A communication interface 418 may be coupled to bus 402 for communicating 
information and conmiand selections to processor 404. hi one embodiment, interface 418 
is a conventional serial interface such as an RS-232 or RS-422 interface. An external 

20 terminal 41 2 or other computer system connects to the computer system 400 and provides 
commands to it using the interface 414. Firmware or software running in the computer 
system 400 provides a terminal interface or character-based command interface so that 
external commands can be given to the computer system. 

A switching system 416 is coupled to bus 402 and has an input interface 414 and 

25 an output interface 419 to one or more external network elements. The external network 
elements may include a local network 422 coupled to one or more hosts 424, or a global 
network such as Intemet 428 having one or more servers 430. The switching system 416 
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switches information traffic arriving on input interface 414 to output interface 419 
according to pre-determined protocols and conventions that are well known. For 
example, switching system 416, in cooperation with processor 404, can determine a 
destination of a packet of data arriving on input interface 414 and send it to the correct 
5 destination using output interface 419. The destinations may include host 424, server 430, 
other end stations, or other routing and switching devices in local network 422 or Internet 
428. 

The invention is related to the use of computer system 400 for the techniques and 
functions described herein in a network system. According to one embodiment of the 

10 invention, such techniques and functions are provided by computer system 400 in 

response to processor 404 executing one or more sequences of one or more instructions 
contained in main memory 406. Such instructions may be read into main memory 406 
from another computer-readable medium, such as storage device 410, Execution of the 
sequences of instructions contained in main memory 406 causes processor 404 to perform 

1 5 the process steps described herein. One or more processors in a multi-processing 

arrangement may also be employed to execute the sequences of instructions contained in 
main memory 406. In alternative embodiments, hard-wired circuitry may be used in 
place of or in combination with software instructions to implement tiie invention. Thus, 
embodiments of the invention are not hmited to any specific combination of hardware 

20 circuitry and software. 

The term "computer-readable medium" as used herein refers to any medium tiiat 
participates in providing instructions to processor 404 for execution. Such a medium 
may take many forms, including but not limited to, non-volatile media, volatile media, 
and transmission media. Non-volatile media includes, for example, optical or magnetic 

25 disks, such as storage device 410. Volatile media includes dynamic memory, such as 
main memory 406. Transmission media includes coaxial cables, copper wire and fiber 
optics, including the wires that comprise bus 402. Transmission media can also take the 
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form of acoustic or light waves, such as those generated during radio wave and infrared 
data communications. 

Common forms of computer-readable media include, for example, a floppy disk, a 
flexible disk, hard disk, magnetic tape, or any other magnetic medium, a CD-ROM, any 
5 other optical medium, punch cards, paper tape, any other physical medium with patterns 
of holes, a RAM, a PROM, and EPROM, a FLASH-EPROM, any other memory chip or 
cartridge, a carrier wave as described hereinafter, or any other medium from which a 
computer can read. 

Various forms of computer readable media may be involved in carrying one or 

10 more sequences of one or more instructions to processor 404 for execution. For example, 
the instructions may initially be carried on a magnetic disk of a remote computer. The 
remote computer can load the instructions into its dynamic memory and send the 
instructions over a telephone line using a modem. A modem local to computer system 
400 can receive the data on the telephone line and use an infrared transmitter to convert 

15 the data to an infrared signal. An infrared detector coupled to bus 402 can receive the 
data carried in the infrared signal and place the data on bus 402. Bus 402 carries the data 
to main memory 406, from which processor 404 retrieves and executes the instructions. 
The instructions received by main memory 406 may optionally be stored on storage 
device 410 either before or after execution by processor 404. 

20 Communication interface 41 8 also provides a two-way data communication 

coupling to a network link 420 that is connected to a local network 422. For example, 
communication interface 418 may be an integrated services digital network (ISDN) card 
or a modem to provide a data communication connection to a corresponding type of 
telephone line. As another example, communication interface 418 may be a local area 

25 network (LAN) card to provide a data communication connection to a compatible LAN. 
Wireless links may also be implemented. In any such implementation, communication 
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interface 418 sends and receives electrical, electromagnetic or optical signals that carry 
digital data streams representing various types of information. 

Network link 420 typically provides data communication through one or more 
networks to other data devices. For example, network link 420 may provide a connection 
5 through local network 422 to a host computer 424 or to data equipment operated by an 
Internet Service Provider (ISP) 426. ISP 426 in turn provides data communication 
services through the world wide packet data communication network now conmionly 
referred to as the "Internet" 428. Local network 422 and Mtemet 428 both use electrical, 
electromagnetic or optical signals that carry digital data streams. The signals through the 
10 various networks and the signals on network link 420 and through communication 
interface 418, which carry the digital data to and from computer system 400, are 
exemplary forms of carrier waves transporting the information. 

Computer system 400 can send messages and receive data, including program 
code, through the network(s), network hnk 420 and communication interface 418. In the 
1 5 Internet example, a server 430 might transmit a requested code for an application 

program through totemet 428, ISP 426, local network 422 and communication interface 
418. In accordance with the invention, one such downloaded application provides for the 
techniques and functions that are described herein. 

The received code may be executed by processor 404 as it is received, and/or 
20 stored in storage device 410, or other non-volatile storage for later execution. In this 

manner, computer system 400 may obtain application code in the form of a carrier wave. 
APPLICATIONS AND ADVANTAGES 
Using the foregoing mechanism, network devices, such as switches and routers, 
can automatically enable quality of service for the flows in the opposite direction based 
25 on the service granted for the original flow for which quality of service was signaled. 

Exemplary applications include video conferencing, other bi-directional video 
applications, Memet Protocol telephony, and client-server applications in which the links 
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from the clients to the server are also congested and require prioritization, hi any of these 
apphcations and others, a network administrator may rapidly and easily provide bi- 
directional quaUty of service. Devices in the network can be configured to automatically 
provide quaUty of service for the opposite direction of a flow so that the network 
5 administrator need only classify the traffic from one of the endpoints. 

The techniques disclosed in this document are very useful in a one-to-many 
configuration, for example, a server with many clients. The packets may be marked on 
the switch near the servers, and then all switches near the clients are configured to simply 
mark the opposite flows with the same DiffServ value. Current solutions might require 

10 configuring many different ACLs on each and every switch; potentially at least one ACL 
for each server for quality of service is required. 

Another context is an ISP network, for example, an ISP network that provides 
virtual private network services, in which a first peer node is within the network and a 
second peer node is outside the network. The ISP may mark traffic fi*om the first node, 

15 for example, by creating and storing an appropriate ACL on the switch or router that is 
adjacent to the first node. However, for each such node the ISP would have to install a 
similar ACL on all network devices at the border or edge of the network and going into 
other ISPs, Further, these ACLs might need to be added and removed dynamically as 
network flows are created and stopped. 

20 Advantageously, an embodiment permits the ISP to configure its border routers to 

mark each flow going through them with the same DSCP on the opposite direction. The 
network administrator then needs to ensure only that traffic is marked correctly within his 
network. 

In the foregoing specification, the invention has been described with reference to 
25 specific embodiments thereof It wiU, however, be evident that various modifications and 
changes may be made thereto without departing fi-om the broader spirit and scope of the 



50325-0124 (2145/64741) 



-22- 



invention. The specification and drawings are, accordingly, to be regarded in an 
illustrative rather than a restrictive sense. 
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CLAIMS 

What is claimed is: 



11. A method of converting an abstract quality of service policy into a new configuration 

2 for one or more network devices, the method comprising the computer-implemented 

3 steps of: 

4 receiving and converting the abstract quaUty of service policy into a first set of one or 

5 more basic commands; 

6 receiving one or more first command line interface (CLI) commands that represent a 

7 current configuration of a network device; 

8 determining a second set of one or more basic commands that correspond to the 

9 current configuration of the network device, based on the first CLI commands; 

10 transforming the first and second sets of basic commands into one or more second 

1 1 CLI commands which, when executed by the network device, will create a 

1 2 new configuration for the network device that implements the abstract quality 

13 of service policy. 

12. A method as recited in Claim 1 , wherein the step of transforming the first and second 

2 sets of basic commands comprises the steps of merging and aggregating the first and 

3 second sets of basic commands by eliminating dupUcate commands and combining 

4 similar commands. 

13. A method as recited in Claim 2, wherein the steps of receiving and converting the 

2 abstract quality of service policy comprise the steps of: 

3 receiving and analyzing one or more abstract pohcies that are defined by a user using 

4 a quality of service management system; 

5 creating one or more corresponding instances of basic command objects, to result in 

6 creating and storing an initial set of basic commands that represent the abstract 

7 policies. 



50325-0124 (2145/64741) 



-24- 



1 4. A method as recited in Claim 3, wherein the steps of receiving one or more first 

2 command line interface (CLI) commands and determining a second set of one or more 

3 basic commands comprise the steps of: 

4 receiving the initial set of basic commands; 

5 analyzing a current configuration of the network device; 

6 determining a third set of one or more CLI commands which, if executed by the 

7 network device, would result in creating the current configuration; 

8 converting the third set of one or more CLI commands into a set of one or more 

9 uploaded basic commands. 

1 5. A method as recited in Claim 4, wherein the steps of merging and aggregating the first 

2 and second sets of basic commands comprises the steps of: 

3 receiving the set of uploaded basic commands; 

4 comparing the initial set of basic commands to the set of uploaded basic commands; 

5 creating and storing a final list of basic commands by determining a minimal set of 

6 basic commands which, if executed by the network device, would result in 

7 creating a new device configuration that implements the abstract policy, 

1 6. A method as recited in Claim 5, further comprising the steps of assigning a state value 

2 of each basic command in the final list of basic commands upon creation of each 

3 basic command. 

17. A method as recited in Claim 6, wherein the step of transforming the first and second 

2 sets of basic commands comprises the steps of: 

3 receiving the final list of basic commands; 

4 based on the state value of each basic command in the final list, translating each basic 

5 command in the final list into one or more second CLI commands which, 

6 when executed by the network device, will create a new configuration for the 

7 network device that implements the abstract quality of service policy. 
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1 8. A method as recited in Claim 1 , further comprising the step of assigning a state value 

2 of DO to each basic command in the first set upon creation of such basic command, 

3 wherein such state value indicates that the associated basic command must be 

4 deployed to the network device as part of deploying the new configuration, 

19. A method as recited in Claim 1 , further comprising the step of selectively assigning a 

2 state value UNDO or EXIST to each basic command in the second set of basic 

3 commands, wherein a state value of UNDO indicates that the associated basic 

4 command should be removed from the network device as part of deploying the new 

5 configuration, and wherein a state value of EXIST indicates that the associated basic 

6 command is currently configured on the network device and may be removed or 

7 retained as part of deploying the new configuration, 

1 10. A method as recited in Claim 8, wherein the steps of merging and aggregating the first 

2 and second sets of basic commands comprises the steps of: 

3 based on the state value of each basic command in the final list, translating each basic 

4 command in the final list into one or more second CLI commands which, 

5 when executed by the network device, will create a new configuration for the 

6 network device that implements the abstract quality of service policy; 

7 when two of the basic commands in the final list are equivalent without considering 

8 their associated state values, and when one of the two commands has a state 

9 value of DO and the second of the two commands has a state value of UNDO, 

10 merging the two commands into one new command having a state value of 

11 EXIST. 

1 11. A computer-readable medium carrying one or more sequences of instructions for 

2 converting an abstract quality of service policy into a new configuration for one or 

3 more network devices, which instructions, when executed by one or more processors, 

4 cause the one or more processors to carry out the steps of: 

5 receiving the abstract quality of service policy; 
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6 converting the abstract quality of service policy into a first set of one or more basic 

7 commands; 

8 receiving one or more first command line interface (CLI) commands that represent a 

9 current configuration of a network device; 

10 determining a second set of one or more basic conmiands that correspond to the 

1 1 current configuration of the network device, based on the first CLI commands; 

12 transforming the first and second sets of basic commands into one or more second 

1 3 CLI commands which, when executed by the network device, will create a 

14 new configuration for the network device that implements the abstract quality 

15 of service policy. 

1 12. An apparatus for converting an abstract quality of service policy into a new 

2 configuration for one or more network devices, comprising: 

3 a quality of service management system that is coupled to a managed network 

4 comprising the one or more network devices and including means for creating 

5 and storing an abstract policy defining a quality of service for use by the 

6 network devices in carrying one or more network traffic flows; 

7 means for converting the abstract quality of service policy into a first set of one or 

8 more basic commands; 

9 means for receiving one or more first command Une interface (CLI) commands that 

10 represent a current configuration of a network device; 

1 1 means for determining a second set of one or more basic commands that correspond 

12 to the current configuration of the network device, based on the first CLI 

13 conmiands; and 

14 means for transforming the first and second sets of basic commands into one or more 

15 second CLI commands which, when executed by the network device, will 

1 6 create a new configuration for the network device that implements the abstract 

17 quality of service policy. 

1 13. An apparatus for converting an abstract quality of service poUcy into a new 

2 configuration for one or more network devices, comprising: 
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3 a quality of service management system that is coupled to a managed network 

4 comprising the one or more network devices and including means for creating 

5 and storing an abstract policy defining a quality of service for use by the 

6 network devices in carrying one or more network traffic flows; 

7 basic command processing logic coupled to the quality of service management system 

8 and comprising one or more sequences of instructions which, when executed by 

9 one or more processors, causes the one or more processors to execute the steps 

10 of: 

1 1 converting the abstract quality of service policy into a first set of one or more 

12 basic commands; 

13 receiving one or more first command line interface (CLI) commands that 

14 represent a current configuration of a network device; 

15 determining a second set of one or more basic commands that correspond to the 

16 current configuration of the network device, based on the first CLI 

17 commands; and 

1 8 transforming the first and second sets of basic commands into one or more 

19 second CLI commands which, when executed by the network device, 

20 will create a new configuration for the network device that implements 

21 the abstract quality of service policy, 

1 14. A method as recited in Claim 1 , wherein each basic command expresses control for a 

2 network device at an intermediate level of abstraction that is lower than the abstract 

3 policy and higher than the CLI commands. 

1 15. In a quality of service policy management system that controls deployment of quality 

2 of service policies to a plurality of routers in a managed network, a method of 

3 converting an abstract quality of service policy into a new configuration for one or 

4 more of the routers, the method comprising the computer-implemented steps of: 

5 receiving tiie abstract quality of service from the quality of service policy 

6 management system; 

7 converting the abstract quality of service policy into an initial set of one or more basic 

8 commands; 
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9 receiving one or more first router command line interface (CLJ) commands that 

10 represent a current configuration of one of the routers; 

1 1 determining a set of one or more uploaded basic commands that correspond to the 

12 current configuration of the router, based on the first CLI commands; 

1 3 creating and storing a final set of basic commands based on the initial set of basic 

14 commands and the uploaded basic commands; 

1 5 transforming the final set of basic commands into one or more second CLI commands 

16 which, when executed by the router, will create a new configuration for the 

17 router that causes the router to implement the abstract quality of service 

18 policy. 

1 16. A method as recited in Claim 15, wherein the step of transforming the final set of 

2 basic commands comprises the steps of merging and aggregating the initial set and 

3 uploaded basic commands by eliminating duplicate commands and combining similar 

4 commands. 

1 17. A metiiod as recited in Claim 15, wherein the steps of determining a set of one or 

2 more uploaded basic commands comprise the steps of: 

3 receiving the initial set of basic commands; 

4 analyzing a current configuration of the network device; 

5 determining an interim set of one or more CLI commands which, if executed by the 

6 network device, would result in creating the current configuration; 

7 converting the interim set of one or more CLI conraiands into a set of one or more 

8 uploaded basic commands. 

1 18. A method as recited in Claim 16, wherein the steps of merging and aggregating the 

2 initial first and second sets of basic commands comprises the steps of: 

3 receiving tiie set of uploaded basic commands; 

4 comparing the initial set of basic commands to the set of uploaded basic commands; 

5 creating and storing a final list of basic commands by determining a minimal set of 

6 basic commands which, if executed by the network device, would result in 

7 creating a new device configuration that implements the abstract policy. 
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1 19. A method as recited in Claim 15, further comprising the steps of assigning a state 

2 value of each basic command in the final list of basic commands upon creation of 

3 each basic command. 

1 20. A method as recited in Claim 15, further comprising the step of assigning a state value 

2 of DO to each basic command in the initial set upon creation of such basic command, 

3 wherein such state value indicates that the associated basic command must be 

4 deployed to the netv^ork device as part of deploying the new configuration. 

1 21 . A method as recited in Claim 15, further comprising the step of selectively assigning 

2 a state value UNDO or EXIST to each basic command in the set of uploaded basic 

3 commands, wherein a state value of UNDO indicates that the associated basic 

4 command should be removed from the network device as part of deploying the new 

5 configuration, and wherein a state value of EXIST indicates that the associated basic 

6 command is currently configured on the network device and may be removed or 

7 retained as part of deploying the new configuration. 

1 22. A method as recited in Claim 21 , wherein the steps of merging and aggregating the 

2 initial and uploaded sets of basic commands comprises the steps of: 

3 based on the state value of each basic command in the final list, translating each basic 

4 command in the final hst into one or more second CLI commands which, when 

5 executed by the network device, will create a new configuration for the network 

6 device that implements the abstract quality of service pohcy; 

7 when two of the basic commands in the final list are equivalent without considering 

8 thek associated state values, and when one of the two commands has a state 

9 value of DO and the second of the two commands has a state value of UNDO, 

1 0 merging the two commands into one new command having a state value of 

11 EXIST. 
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ABSTRACT OF THE DISCLOSURE 

A method of converting an abstract quality of service policy into a new configuration for 
one or more network devices of a managed network, such as routers. The policy 
expresses a quality of service treatment of traffic flows that are carried by the network, at 
5 a high level of abstraction, and is created and stored using a quality of service policy 
management system. According to an embodiment of the method, the abstract quality of 
service policy is received and converted into a first set of one or more basic commands. 
A current configuration of one of the network devices is obtained, e.g., through device 
discovery. The configuration is received in the form of one or more first command line 

10 interface (CLI) commands that represent the current configuration of the network device. 
A second set of one or more basic commands that correspond to the current configuration 
of the network device is determined, based on the first CLI conunands. The first and 
second sets of basic commands are transformed into one or more second CLI commands 
which, when executed by the network device, will create a new configuration for the 

15 network device that implements the abstract quality of service policy. Merging and 

aggregation, based on state values associated with the basic commands, is carried out to 
itmove any duplicate commands. As a result, CLI commands providing a new 
configuration that implements the policy are deployed to the device. The basic commands 
are expressed at a level of abstraction lower than the abstract pohcy and higher than the 

20 CLI commands. 
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